Web based application constructor using objects as pages

ABSTRACT

A web-based application constructor can be used for constructing a web display. The web-based application constructor can obtain data from heterogeneous data sources to produce the web display. The web display can contain page components and display the data from at least some of the heterogeneous data sources. The application constructor can convert at least one object from a heterogeneous data source into a page component.

CLAIM OF PRIORITY

This application claims priority to U.S. Provisional Application No.60/914,623 entitled “ENTERPRISE WEB APPLICATION CONSTRUCTOR SYSTEM ANDMETHOD”, filed Apr. 27, 2007 [Atty. Docket No. BEAS-02048US0], by MatiasCudich et al., which is herein incorporated by reference.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever.

FIELD OF THE INVENTION

Embodiments of the present invention relate to a seamless, collaborativeenvironment for creating applications, consuming information, andcontributing content.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an overview of a constructor system of one embodiment.

FIG. 2 shows an overview of an architecture of one embodiment.

FIG. 3 illustrates a page constructor flow chart.

FIG. 4 illustrates a request path for an object as a page.

FIG. 5 illustrates a gatewayed page with header diagram.

FIG. 6 illustrates a LiveSpaces tag diagram.

FIG. 7 illustrates a system using annotations.

FIG. 8A-8C illustrates the configuration of pages.

FIG. 9 illustrates an example with a web service invocation framework

DETAILED DESCRIPTION

Embodiments of the present invention enable users to manage informationstored in both native databases and external systems. In concert withthe rich set of page components, data sources can let users createon-the-fly applications that surface critical business information suchas sales leads from a Siebel CRM system, or manage lightweight datasets, such as a product feature list.

One embodiment of the present invention is a web-based applicationconstructor 102 for constructing a web display. The web-basedapplication constructor 102 can obtain data from heterogeneous datasources to produce the web display. The web display 106 can contain pagecomponents 108 and 110 and display the data from at least some of theheterogeneous data sources.

A versioning system 112 can keep track of changes to page components toallow users to make changes without administrative approval. Theversioning system 112 can keep track of changes to page layout,searches, and text to allow users to make changes without administrativeapproval. A change control system 114 can allow users to dynamicallyundo changes to page components while using the web-based applicationconstructor.

The versioning system 112 can store old versions of the web display andthus allow the users to roll back changes. For example, the system canstore a history of old versions and when a user makes an error, the pagecan be rolled back to a previous version.

The page components can be elements constructed from data in theheterogeneous data sources. For example, the page components can exposedata from ERP, Database or other sources.

The heterogeneous data source can be resources with a company. Theheterogeneous data source can include relational database managementsystem, a customer relationship management system; enterprise resourceplanning system and/or any other types of data sources.

The heterogeneous data sources can have Web Services schemas that allowthe application constructor to produce a display of the data. The pagecomponents can contain interactive elements. In one embodiment, all pageediting is versioned.

Whether a page component is displayed to a user can be controlled byroles and security. For example, some pages can have page componentsthat are only viewable by users in a certain group or with a certainsecurity level. Display and/or updates to page components can becontrolled by using the URLs for the page components. The web-basedapplication constructor can provide roles to users that can be used tolimit access to applications.

The page layout can also be versioned. Versions of the page can storedat a remote server. AJAX at a user browser can send version updateinformation to the remote server. Page templates can be used to createthe display. The page components can include rich text.

The page components can have their own URL so that they can be sharedamong applications. For example, a user can copy a page component intotheir own page since the system can use the page components URL to copyit into a new display page. In this way, updates can be sent to multiplepages.

The page components can include a view of data in a list, a view of datain a record, a view of an ad-hoc application or other views. The displaycan be constructed from available applications, where availableapplications can be dragged and dropped into page components.

In one embodiment, at least one of the heterogeneous data sources is asearchable resource. When the display provides for a search field intothe searchable resource, the result of a search can be shown in a pagecomponent of the display. The page components can be dragged and droppedto a new display. In one embodiment, the changes to the page componentare not propagated back to the application data source propagated backto the application.

The web-based application constructor can provide roles to users thatcan be used to limit access to applications. The application constructorcan convert at least one object from a heterogeneous data source into apage component. The system can allow for the construction of userinterfaces to access different types of data.

Change control system 114 can allow users to dynamically undo changes topage components while using the web-based application constructor.

All page editing can be versioned. The change control system can allowfor a redo of changes. The versions can be time stamped and changes canbe rolled back up. For example in one embodiment, users can rollbackchanges to a state as of a previous period of time. Changes can bedynamically made to page components, page layout, searches, and textwhile using the web-based application constructor.

In one embodiment, the web-based application constructor can allow usersto annotate page components with comments visible in the web display.

In one embodiment, the page components can be identified by URLs and theannotations can be associated with the URL. In one embodiment, theannotations can receive user inputs from multiple pages and produce acommon display. A web-based text editor can be used for the annotations.

FIG. 7 shows an example with a page 702 having page components 704 and706. Annotation 708 can be created to be associated with the pagecomponent 704. Drag and drop selections 712 can be used to drag and droppage commands and annotation boxes onto page 702. Page Component B canalso be dragged and dropped from page 702 into page 714.

One embodiment of the present invention includes an applicationconstructor to convert at least one object from a heterogeneous datasource into a page component.

In one embodiment, the system allows for the construction of userinterfaces to access different types of data. Web service WSDL can beanalyzed to determine user interface fields. An XML editor framework cananalyze XML schema at the WSDL.

The page components are accessible by URLs. URLs can be used by asecurity system. The Roles can be used to determine what page componentsare displayable to as user.

The URLs can be automatically created. All elements on a page can haveits own URL.

The page components can contain interactive elements.

An XML editor framework can be adapted to use web services schemas toautomatically create a user interfaces for inputting data in fieldsdetermined from the web service schemas. Page components can containdata that has been converted into a list format. Clicking on elements ofthe list can access additional details of the list. The list can beannotated.

The page components can be extensible.

The page display can have a nested layout. The nested layout can includerows and columns in a cell defined by rows and columns. Different rowscan have different numbers of columns. The page components can bedragged and dropped so as to change the layout. New columns and/or rowscan be created by the dragging and dropping.

The page components can be defined as being positioned left, right, upor down of a previous page layout location. The HTML can be updated at aserver as a result of the dragging and dropping.

Different rows can have different numbers of columns.

FIGS. 8A and 8B show an example of the dragging and dropping of a pagecomponent so that a new row is created.

FIG. 8C shows an example where a cell within a row and column locationcan have rows and columns. The page components 812, 814 and 816 are inthose positions.

AJAX at a browser can send page layout instruction to a server to createnew HTML for a page. The AJAX can update the page at the browser withoutrefresh.

In one embodiment, the application constructor can allow querying of thedata sources.

FIG. 9 shows an example with a web service instruction framework 902used to access data sources 906 for a constructor API 904. The datasources 906 can us web schemas that allow for the access by the webservices invocation framework 902. Abstraction layer 908 can provide fora UI on top of the constructor API 904.

The Web Services Invocation Framework (WSIF) is a simple Java API forinvoking Web services, no matter how or where the services are provided.

WSIF enables developers to interact with abstract representations of Webservices through their WSDL descriptions instead of working directlywith the Simple Object Access Protocol (SOAP) APIs, which is the usualprogramming model. With WSIF, developers can work with the sameprogramming model regardless of how the Web service is implemented andaccessed.

WSIF allows stubless or completely dynamic invocation of a Web service,based upon examination of the meta-data about the service at runtime. Italso allows updated implementations of a binding to be plugged into WSIFat runtime, and it allows the calling service to defer choosing abinding until runtime.

DETAILED DESCRIPTION OF ONE EXEMPLARY EMBODIMENT

The following describes one exemplary but non-limiting example of asystem of the present invention.

Page editing can include:

-   -   Classic wiki-style page creation and editing    -   Performed by typical end users as part of using the system    -   Pages can be designed to evolve over time, by being edited by        multiple users over multiple edit sessions (which can be        concurrent)    -   Example pages: product launch workspace, article on customer        wiki pages, etc.

State and mode management can be done in multiple ways. In oneembodiment, regardless of the shell applied to the given page/livespace, users can specify a mode and a state for the page they areviewing or editing. When in Read mode, there is only one state—read.When in Edit or Decorate mode, users can switch between Insert and Writeedit states, each of which can have an associated set of controls/UIs.These modes and states can be independent of the shell applied to thepage.

The primary toolbar can be the main mode controller for the page,allowing users to switch between Read and Edit modes.

The secondary toolbar can allow users to perform actions associated witheach mode. Also, when in Edit or Decorate mode, users can use thesecondary toolbar to specify a state for the page.

Read mode can allow users to perform actions that don't alter the actualcontents of a given page. For example, when viewing a page in read mode,users can add comments, documents, and create new pages.

In one embodiment, edit mode does allow users to alter the contents ofpages, either by inserting, moving, or deleting page components, or byentering or deleting rich text. The actions a user can perform can begoverned by the state the page is in.

While in Read mode, users can create new pages. To create a new page,users can specify a page title, a URL for the page (this can beautomatically generated by the form, but users can override the URL ifthey so desire), and a description for the page. Moreover, users canspecify a layout for the page, and the Live Space in which the page willlive. By default, pages can be placed in the current Live Space; usersdo have the opportunity, however, to place the page in another LiveSpace—either one that exists, or a new one they create on the fly.

Once a page is created, users can go back and modify certain settings,and view properties for that page. This uses the same user interface forcreating a page. In one embodiment, users can change the followingsettings/properties once a page is created: title, name, anddescription, parent Live Space.

In one embodiment, users can add comments to pages while in Read mode.

Users can add documents to pages while in Read mode.

While in the Insert edit state, users can drag-and-drop components on toa given page, delete components that already exist on a given page, movearound components that already exist on a given page, and enter intoconfiguration wizards for all components on a given page. When in Insertedit state, the secondary toolbar updates to display a list of componenttypes that the user can add to a given page. Users can also drill into asecondary UI (Chooser) to pick a component type or component instancenot listed in the secondary toolbar. Note that the component typeslisted in the secondary toolbar can be draggable items that can bedragged on to the page. While in Insert edit state, each component on agiven page is automatically disabled (e.g., while in Insert edit state,users cannot sort or add rows to a data table).

While in Insert edit state, users can drag and drop components into apage. To drag and drop a component into a page, a user simply mouse'sdown on one of the component types listed in the Insert edit statesecondary toolbar, and then drags that on to the page. Once the dragitem is inside a valid insert target (as defined by the current layout),the page can update to display a “shadow marker” of where the componentwould live if it where dropped into the page. Users can place componentsinto empty insert targets, or into insert targets which already containother components. When placing a component into an empty insert target,it's fairly straightforward—the page shows a shadow marker inside theempty insert target (the shadow marker should fill up the entire inserttarget) and when the user drops the item, the page refreshed to displaythe new component. When adding a component next to an existing component(inside a non-empty insert target), users can decide to place the newcomponent to the left, right, top or bottom of the existing component.If placing the new component to the left or right of an existingcomponent, the existing component and other components on the same “row”can condense to make room for the new component. If placing a componentabove or below an existing a component, a new “row” can be created toaccommodate the new component.

Upon adding a new component to a page, or when clicking theSettings/Properties button on a component's toolbar while in Insertmode, the application can pop up a Settings wizard, which lets a userconfigure settings for a given component. Each component type has itsown wizard, which each instance of that type uses to let users specifysettings such as Title, Description, Dataset, and so on.

While in Write edit state, users can add rich text to a given page. Inone example, there are three possible workflows that lead to this: (a) auser drags and drops a Text page component on to a page, at which pointthe page switches from Insert to Write edit state, or (b) a user clicksthe Write edit state button on a page with no existing rich textcomponents at which point a default text component is added for the userby the application, or (c) a user clicks the Write edit state button ona page that already has one or more text components on it, at whichpoint each of those components becomes editable. While in Write editstate, each component on a given page is still enabled, and usable(e.g., a user can write and add a new row to a data table while in Writeedit state).

While in Write edit state, users can add new rich text to a page, andmodify existing rich text. To apply formatting to rich text, a userfollows similar steps to formatting rich text: highlight text, applyformatting, etc. Users are also able to paste in rich text from othersources (e.g., Word, Web, etc.) and have the rich text formattingmaintained to some degree.

As noted above, users can specify a layout for a page when creating apage. For example, a user can decide that a page should have atwo-column layout, a header-body-footer layout, and so on. The purposeof layouts is to allow users to arrange page components in ways thatsuit their needs. Layouts can be comprised of “insert targets” orcontainers arranged in a particular way. At their core, layouts can bejust XHTML templates, with some CSS to specify how that XHTML isrendered on the page. When in Insert edit state, layouts constrain whereon a page components can be placed. In some cases, a layout may containareas into which components can't be placed. In one embodiment, a page'schosen layout can't be changed once the page is created. Layouts can bestored and edited on the file system in the /webtier/layouts directory.

Upon making changes to a page—either by adding, removing or moving acomponent, or by adding or modifying rich text—a user can decide to savethe page as a draft or to publish the page. When saving a page as adraft, users are specifying that only they, and no other user, shouldsee their changes to the page. Only until a user publishes their changescan other users see those changes. A page will only let users save orpublish a page when an actual change has been made by the user. Bydefault, when a change is made in Insert edit state, the page isautomatically saved as a draft; when a change is made in Write editstate, the page is automatically saved as a draft, but on a timedinterval. To be clear, users can save a page as a draft, close theirbrowser, come back two weeks later, and they will still have theirchanges saved to the system, but not yet published.

During a given edit session, users can undo, redo and cancel theirchanges. While in Insert edit state, users can undo/redo adding a newcomponent, removing a component, moving components, and changingcomponent settings. While in Write edit state, users can undo/redomodifying rich text. If a user wants to discard changes in a given editsession, they can simply hit Cancel. The undo stack is currently limitedto ten items by default, but will be configurable.

Users can view past versions for a given page, which is a list of allpublished edits to a given page. Users can do a number of things for agiven version: (a) they can navigate to a given version to see how thepage looked at a certain point in time, (b) they can delete a givenversion, and (c) they can revert to a given version. When navigating toa given version, the page can only be in Read mode. When deleting agiven version, the version list updates, but none of the version numberschange. When reverting to a given version, the existing version isn'tremoved, but the page's “current version” is changed. If a user makes anedit to a current version that's earlier than some other version, thenew published version is simply added to the end of the version list.

FIG. 2 illustrates an example of one architecture of a system of thepresent invention.

Examples of page objects can include:

-   -   id    -   name    -   title    -   description    -   children        -   components            -   e.g., image    -   layout        -   static XHTML, CSS        -   insert targets

Glue code can be used to transform Constructor-specific page tree intoXHTML understood by JSF/Facelets, which then simply turns that all intoHTML.

FIG. 3 shows a flow chart for constructing pages in one embodiment.

When entering Edit mode, JavaScript (via CSS) can highlight the areas ofthe page into which users can place components. In one embodiment, theseinsert targets are always there, but only ever get enabled (byJavaScript) when the user enters the appropriate edit state. Going intoEdit mode need not make any server requests (with the caveat of checkingout the page).

Direct Web Remoting (DWR) can let you call operations/methods on theserver via JavaScript. DWR PageService is an abstraction of theserver-side PageManager interface. The PageManager allows performingcreate/read/update/delete operations on/for a given page.

Example call:

-   -   dwr.PageService.insertNewComponent(component)-JavaScript->DWR        Ajax call to server-JavaScript/Java        Servlet->PageService.insertNewComponent(component)-Java->DWR        Response-HTTP->page.updatePageWithNewHTML-JavaScript.

Dojo can be used for all JavaScript operations on the client, primarilygathering DOM objects, updating styles on those objects, updating pagemodes and edit states, parts of drag-and-drop, rich-text editing,console logging, and so on.

The Image Component can allow users to embed images into Constructorpages. For example, one could imagine going to a page that lists outrecent customer bugs. One might want to display in this page ascreenshot of a recent bug file by a customer. By using the imagecomponent, users can embed this type of information alongside othercomponents, such as rich text, data tables and so on. Users can also, inthe context of a rich-text editing session, embed an image in the middleof some text. This is supported and managed by the rich text editor, butuses the same editor UI as the image component.

Upon dropping the image component on to a page, users can specify asource URL for the image. This can be any URL that is accessible bybrowsing users (meaning that the server doesn't copy the URL source orproxy the request to the image). So, if the URL is down, the image willalso be down. In one embodiment, users must specify fully qualified URLsor URLs relative to the Constructor root context path.

Users can also upload images to the system, if for example, they havethe image sitting on their desktop and they want to share it via aConstructor page. To upload an image, users must find the image on theirdesktop, and then hit Upload. After the image is uploaded, the user canthen hit Finish or Cancel. If they hit Finish, the image is thenattached as a file to the page, and displayed as an image via the imagecomponent. Since these images are attached as files to pages, alldocument management functionality is available, meaning that theseimages can be versioned, etc. Images can also be deleted ex post facto,and if so, the image component can display a friendly message statingthat the image it's pointing at has been deleted.

Users can also point at an image which is already attached to the givenpage. Here, upon picking an image from this list, the editor displays apreview of the image. If a user swaps the image, the old image is notdeleted.

Whenever a user points at a URL, uploads an image, or chooses an imagealready attached to the page, the editor is designed to give a previewimage. This preview can be a scaled-down version of the original image.The scaled down version can maintain the original aspect ratio of theimage, and doesn't exceed a specified maximum height or width.

The image component can support all file types supported by the browsersin our support matrix.

When specifying an image, the editor automatically grabs the width andheight attributes for that image, and sets those for the imagecomponent. This allows the page to automatically distribute componentsto the left and right of an image component, so that the contents of theimage component are not cut off. We will provide a suggestion to usersthat they shouldn't add to pages images greater than a certain width,such as 1024 px wide (minimum browser width). Users can override theautomatically specified height and width values generated by the editor.

The Image Component can automatically resize images to fir the columnthey're in. If an image is smaller than the column it's in, its sizedoesn't change. If the image is too wide, then it can be scaledappropriately to fit. Images need not automatically resize when thewindow size changes; they do, when the sidebar is toggled on and off inthe default shell.

The image component can automatically add the image title text asalternative text on the IMG tag inside the image component.

The image component editor can be based on the XML Editor Framework.This supports all of our wizard rendering, help text, and all of theform fields that show up (including their validation).

Images can be stored in the content repository as attachments to pages(just like other documents).

Image titles and descriptions can be indexed by the search engine.

Images attached to pages can be fetched via the Constructor documentdownload servlet. To get a given document, you pass in a document ID andversion number (optional).

Image properties are checked asynchronously (this is used when eitherpointing at a URL or uploading a new image).

While users can add free-form content to pages using rich text andcomponents, they also may want to add to pages unstructured contentliving inside of Word documents, PowerPoint presentations and so on.Here, Constructor allows users to attach to pages any kind of document,and perform basic document-management operations on these documents,such as upload, download, and version, revert, and delete.

Users can upload one or more documents using the Add Document wizard ina given page. There is no hard limit on the number of documents that auser can upload simultaneously. Once a document is specified for upload,users can revert that decision by clicking the red button next to thefile upload control. Users can browse to any location their browserknows how to get to (file path, UNC path, etc.). When a user hits Uploadon this wizard, every one of the files chosen is uploaded, and theprogress is displayed via a progress bar. If an error is encounteredduring upload (exceeded maximum upload size, timeout, etc.), the errorwill be displayed in the wizard, and the user will get another chance tochange their list of upload files, and try to upload them again. Oncethese files are attached/uploaded, they will appear in the Info panel.

When a document is attached/uploaded, the system can store metadataabout that document: name, file size, the name of the user who uploadedthe file/version, version number, date stamp, content type, and textpreview (first 100 characters). All of this metadata is then availablevia the Info panel and Document as Page UI. None of this metadata isdirectly user-editable.

Users can download a given document from a variety of locations: Infopanel, Document as Page UI, link inside of a rich-text area. Alldownloads are passed through the Constructor download servlet.

If a user has already uploaded a given document, and then makes somechanges to that document, and wants to update the version attached tothe page, they simply have to go to the page, click Add Documents, andthen point at the new version sitting on their desktop. Because both ofthese versions share the same name, Constructor can know that the userintends to increment the version of the document already attached to thepage. It is important to note that this comparison is done only againstthe name of the latest version.

Every document attached to a page has its own page/URL. When younavigate to the document (via the Info panel, Organizer, etc.) you canperform the following operations: upload a new version of the document,delete a version of the document, delete all versions of the document,revert to a version of the document, and decorate the document.Decorating a given document-page is identical to decorating arecord-page or recordlist-page. Like these other objects, only one pageexists for any given document.

If a user wants to create a new version of a specific document, userscan navigate to the document (document as page), and click Upload NewVersion. This allows users to upload a new version of the given documentthat perhaps has a different file name. Once this happens, the operativefile name of the document changes to the file name of the latestuploaded document. This is important when it comes to figuring outwhether or not to increment a given document, or create a new attachmentwhen a user tries to do a simple file version task. The system need notbe designed to look at old versions of a given document when figuringout whether or not to increment a document's version history.

Users can revert to any version of a given document. This can be aversion uploaded before or after the version labeled as “current”. Forexample, a user can upload five versions of a document, and then decideto revert to version 3. At this point, all five versions still exist,but version 3 is the “current” version. Then, a user can choose torevert to an even earlier version, or back to the latest version. If auser reverts to a previous version, then uploads a new version, theversion list is incremented by 1 (meaning the new version would beversion 6 and versions 4 and 5 would remain). When figuring out whetheror not to increment a document, Constructor looks at the “current”version, not the latest version.

Users can delete any version of a document. Once this version isdeleted, it cannot be recovered. There is no way to delete the “current”version.

Users can completely delete a document (which implies deleting allversions of a document). The document-page representing this documentwill be deleted along with the document. Also, links to the documentwill no longer work.

Objects as Pages can be used to represent structured data, such asrecords, lists of records, documents, and so on, as pages to whichunstructured content can be added. For example, Constructor allowsdisplaying a record such as a Customer Bug as a page; users can thenview this customer bug as a page, mark up the page with additionalcontent (using page components and rich text), and comment on the pageusing Annotations. Because Objects as Pages are based on the Constructorpage framework, normal page actions, such as document attachment andpage versioning can also supported. In one example, there are threestandard views for objects as pages:

-   -   Object as Page (Records and Documents)    -   Entry as Page (Records)    -   Object List as Page (Records)

Certain types of objects can be viewed as pages. This can includerecords and documents attached to pages. This view depends on the givenpage to have embedded in it a page component that knows how to displaythe given object. For example, the standard Record Object as Page canuse the Record Detail component; on the other hand, the standardDocument Object as Page can use the Document Detail component. Thesecomponents handle operations such as updating the object, and deletingthe object to which they are bound. All of these pages support anoperation currently called “Decoration”. Decoration is identical topage-editing, except that it's done in the context of an Object as Page.The distinction here is that there are certain modifications to the areainto which users can add content.

Pages are designed to allow users to add net new objects to acollection. In one example, adding net new records to data sets can besupported. When users navigate to a given Entry as Page, the first thingthey should see is a blank form (this is actually an empty Record Detailcomponent). Else, they are navigating to an existing record, in whichcase they would actually be looking at an Object as Page. Entries asPages support “decoration” in the same way that Objects as Pages support“decoration”.

These pages are designed to allow users to view multiple records in agiven data set via this page construct. The default component used todisplay these records is the Data Table. Much like Objects as Pages andEntries as Pages, these pages can be “decorated” by users.

Each Object, such as Page, Entry as Page and Object List as Page canhave its own unique URL. This can allow users to navigate to these viewsfrom outside of Constructor (which lets them do things like e-mailaround links, etc.). When the name of the given underlying objectchanges, so can the URL, except in the case of documents, who's URLs arebound to IDs rather than user-specified names. URLs to records are alsoID bound, but they do include the name of their owning record set, whichcould be updated by users.

Constructor need not create or store Objects as Pages until those pagesare decorated and subsequently published by users. Also, these pages canbe persisted when Annotations are added to a page (even if the pagehasn't been decorated).

Every Object as Page can have one or more base components it uses todisplay the given object to which the page is bound. In the case ofregular Objects as Pages, the default view can contain a Record DetailComponent, in the case of document Objects as Pages, the default viewcan contain a Document Detail component, and so on. There are cases,however, where other components may be used (in the case ofApplications, for example). These base components may differ slightly infunctionality from their regular versions: for example, the normalRecord Detail component that can be added to any page supports pagingbetween records using an AJAX operation (the page doesn't refresh). Inthe case of the Object as Page version, paging between records actuallynavigates the user among each of the URLs for each of the records in thegiven record set. Some components in the system may only be availablevia Objects as Pages (such as the blog and document detail components).This list will be finalized as we near feature complete.

Objects as Pages can be versioned just like any other page. In oneembodiment, only decoration-level operations are tracked, and notchanges to the underlying object. So, for example, if I go to an ObjectList as Page and add a new record via the Data Table, I'm not actuallyincrementing the page version. Page versions are only added when a userdecorates a page (adds/removes/updates component).

Users can attach documents to Objects as Pages in the same way they canto regular pages. These documents need not be associated with theunderlying data in any way. In one example, if a user attaches adocument to a Record Object as Page, Constructor doesn't automaticallyadd a File Attachment field to the underlying record.

Users can annotate Objects as Pages in the same way they annotateregular pages.

When decorating an Object as Page, there may be restrictions as to whereusers can add content. By default, Objects as Pages will have a primarypage component at the top of the page, and then a blank content areabeneath that. In one embodiment, users are only able to add and managecomponents within this content region. In one example, users cannot addnew components to the left, to the right or above the Object as Pageprimary component.

The Applications feature can make heavy use of Objects as Pages. Here,Objects as Pages act as the View for these Applications. TheseApplications may each have their own custom implementations of Objectsas Pages (for example, the blog application may use a blog component inthe Object List as Page view rather than a data table). This is definedin more detail in the Applications feature specification.

Objects as Pages can be persisted as part of the object they represent.Implications here are: if you create a Record as Page and then deletethat record, that page is subsequently deleted as well.

FIG. 4 shows an example of a request path for an object as a page.

Live Spaces can provide a natural way to group pages, and to provide forthose pages a common access control list, which makes it easy for LiveSpace managers to decide who should be able to see and do what in a LiveSpace, and the pages contained therein.

Users with appropriate access can create new Live Spaces. To create anew Live Space, users can either click a button in the Dashboard, abutton in the Read mode toolbar, or when creating a new page. In thefirst two cases, this pops up a wizard. In the case of creating a LiveSpace when creating a new page, this is done in line, in the pagewizard. When creating a new Live Space from scratch, users can define anumber of settings. These include: Title, URL, Description, Home Page,and Security. When a Live Space is first created, the Home Page can becreated by default. When a user is finished filling in these settings,they can click Finish, and are navigated to the home page of the newLive Space.

Users with appropriate access can modify an existing Live Space'ssettings. All the settings described above can be modified after a LiveSpace has been created. If a user changes the URL for a Live Space, andhits Finish, the browser can reload the page to display the Live Spacewith the new URL.

Users can specify a page for a Live Space, which acts as the defaultpage when anyone tries to navigate to the Live Space directly. Forexample, if a user types in a URL like http:// . . . /Is/foo, they areimmediately navigated to the home page for the ‘foo’ Live Space. At anytime, users with appropriate access can change the home page of a givenLive Space. If a page set as a home page is deleted, the system willalert the user of the fact that they are deleting the given Live Space'shome page, and give them the option to switch to another page as thehome page.

Users can view general properties for a given Live Space by launchingthe wizard for that Live Space. In one embodiment, this tab in thewizard only shows up after a Live Space has been created. This tab caninclude system information such as: date created, date modified, createdby, and so on. None of these properties need be editable. Live Spacescan be represented in the system by a LiveSpace object, which cancontain properties for all the configurable settings noted above. TheLiveSpace object can be persisted in the repository as a node (and onthe filesystem as an XML file). In the repository persistenceimplementation, the pages for a given LiveSpace can be represented aschild nodes under the parent LiveSpace node. While, in one embodiment,certain nodes under the LiveSpace (pages, documents) are versionable,the LiveSpace node need not be. Within the Constructor service tier,LiveSpace objects can be cached, thereby reducing the need to make aremote repository request every time a LiveSpace is requested. In termsof exposing the LiveSpace object through the UI (exposing propertieslike the LiveSpace name as text on the page, or editing LiveSpaceproperties via the editor), there are several mechanisms through whichthis can be surfaced. One is through Facelets and a LiveSpace “backingbean”, which allows properties on the LiveSpace to be rendered in the UIvia certain expressions (EL) in the template's tags. The Live Spaceeditor can update settings on the LiveSpace object by way of the DWRLiveSpaceService, which can expose methods to the client tier (such asJavaScript) to create and update LiveSpace objects. Navigating to a LiveSpace by means of a URL can be handled by a “resource resolver” class,which will parse a URL, and from it, extract the Live Space name (whatis types into the URL field in the editor). From the Live Space name, wecan look up the Live Space, get its home page, and render it.

Page Components can be UI elements which can be added to pages by users.Page components can be bound to back-end data provided by Constructor ora third-party data source, or can simply contain static content, orcontent keyed off of the preferences assigned to a given component. Outof the box, Constructor can ship with a number of page component types,a list from which users can pick to create new page component instances.These can include: Data Table, Image, Record List, Text, and so on.

Any time a user adds a page component to a page, or clicks the EditSettings button on a page component, Constructor can pop up a ComponentEditor, which most of the time takes the form of a wizard. The firsttime a user adds a component to a page, the workflow can be: addcomponent to page->pop up wizard->fill in settings in wizard->clickfinish->refresh component to reflect settings. Users can also cancel outof a wizard during that workflow to cancel adding the component to thepage. Users can also access these wizards after adding a component to apage. Clicking finish or cancel here updates the component, or cancelsout any settings changed in the wizard.

Every component in Constructor can have a URL that can be used to accessthat component directly. In one embodiment, users can get access tothese URLs by either (a) clicking on the component name in the componenttitle bar (for components that have title bars), (b) by viewing theproperties panel for a given component (for components that havewizards/editors), (c) by searching/finding the component in the Explorerpanel and then navigating to the component or (d) by searching/findingthe component in the Organizer and then navigating to it.

In one embodiment, when viewing a page component via a URL, there's aspecific page component shell that wraps the given component. This cantake two forms: (a) user-friendly and (b) portal-ready. In the case of(a), the shell simply displays the page component title and descriptionwithin the shell; in the case of (b) the shell are completely blank andonly displays the contents of the component (not even the title bar).The purpose of (b) is to allow displaying a single page component as aportlet in the portal, where you want to let the portal govern thingslike toolbars, and so on.

Page components can be shared across pages.

Page components need not versioned on their own, or saved on their own.Page components can be versioned and saved as part of a page saveoperation.

Page components, when removed from a page, can be effectively deleted.Users can go back to an old version of a page to get the component back.

This can increments the page undo/redo stack, meaning, if I change thesettings for a given component as part of a page editing session, I canundo those changes.

A Data Table component can expose records in DataSpaces. It can supportvarious modes:

1. Simple: simple mode can simply lists out the records in the DataSpaceto which the Data Table is bound. The record title field shows up as thefirst column, and is a required column. The contents of the title columnare hyperlinked. This hyperlink can navigate users to the correspondingRecord Display page.

-   -   I. Master-Detail: master-detail mode can list out the records in        the DataSpace to which the Data Table is bound. The record title        field can show up as the first column, and is a required column.        The contents of the title column can be hyperlinked. This        hyperlink can display the selected record in the detail view.    -   I. Spreadsheet: spreadsheet mode can list out the records in the        DataSpace to which the Data Table is bound. The record title        field can show up as the first column, and can be a required        column. The contents of the title column can be hyperlinked.        This hyperlink can navigate users to the corresponding Record        Display page. The spreadsheet mode is special in that it lets        users modify the contents of the table as if it were a        spreadsheet (aka in-place editing).        These modes have a lot of functionality in common:    -   View: a given table instance can define the maximum set of        columns that are available for display in the Data Table. This        view is a subset of the total set of fields for the given        DataSpace. This view can be configured in the Data Table wizard,        and can be expressed as a simple multi-select menu. In a view,        users can also specify the default sort column and sort        condition.    -   Show/hide columns: this can be a runtime option (i.e., its state        is not saved across sessions) that lets users hide and show        columns given the set defined by the given Data Table's view.    -   Add row: users can add new records to Data Tables. In Simple        mode, this can be done by clicking the Add Record button, which        navigates users to the Record Entry view for the given        DataSpace. In Master-Detail mode, this can also done by clicking        the Add Record button, except that rather than navigating users        to another page, it can pop open an empty detail view, wherein        users can supply the data for the new record. In Spreadsheet        mode, there can always exist a blank row at the bottom of the        table, wherein users can add new data in place.    -   Delete row: users can delete records in a given DataSpace. In        Simple mode, this can be done by selecting one or more rows (via        a checkbox) and clicking either the Del key or the Delete        button. In Master-Detail mode, this can be done by selecting the        row, and clicking the Delete button in the Detail view. In        Spreadsheet mode, this is done by selecting one or more rows        (via checkbox) and clicking the Del key or the Delete button.    -   Add field/column: if this Data Table is backed by a read/write        DataSpace, clicking this button pops can open the DataSpace        editor, and lets users modify the field settings for the given        DataSpace.    -   Sorting: users can sort columns.    -   Paging and Page Size: in the view for the Data Table, users can        specify the paging size for the Data Table. Once this is        specified, users can take advantage of paging controls to page        back and forth on a DataSpace.        Each mode can also have some unique characteristics:    -   Summary column: in simple mode, the right-most column can always        called Summary. This Summary column can concatenates all the        name/value pairs for the columns which aren't displayed. This        does not include fields not in the view.

The Record List component is designed to allow viewing sizableDataSpaces in a compact, filterable UI.

Once a DataSpace is specified, the following features can be available:

-   -   Summary View: the Record List concatenates the contents of each        record into a compact view: the title field value is the title        of the summary view, and the rest of the fields can be        concatenated into a name/value, comma-delimited string.    -   Filtering: users can filter on the contents of the records        appearing in the Record List. This is a full-text search on the        entire contents of a given record, or set of records.    -   Paging: the Record List can support paging in the same way the        Data Table does.

Search component can be identical to the Record List, except thatinstead of being backed by a DataSpace, it can be backed by a searchresult set. In one embodiment, the following features can be supported:

-   -   Query: users can specify a string that's used to full-text        search for objects in Constructor.    -   Object Type: users can specify a set of object types that can be        used to constrain the result set.    -   Sorting: users can specify sort conditions, based on Title,        Relevance or Date.        Once the query is defined, the UI for interacting with the        results is:    -   Summary View: the Search can concatenate the contents of each        search results into a compact view: object title, object        description, object last modified, and so on.    -   Filtering: users can further filter the contents of the result        set, which effectively appends the principal query string with        an AND operator, and the contents of their new filter query. The        effect is to further scope the result set.    -   Paging: the Search component can support paging in the same way        the Record List does.

Users can add comments, and engage in message-board style discussions,in the context of every page in the Constructor system. This can providea simple way for users to provide structured feedback to the page. Inaddition, it enables things like commenting on blog posts in the contextof blog DataSpaces.

Users can add comments to any page (or type of page) in one of two ways:(a) via the Add Comment button in the toolbar or (b) via the Commentspage component. In the former case, this can pop up a simple editor witha single text box into which a user can add a plain-text comment. Uponhitting the Post button, the comment can be posted. If any of thecomment display UIs are shown (discussed below), those UIs can berefreshed to display the new comment. In the latter case, clicking AddComment inside the page component toggles open a text box into which auser can add a plain-text comment. Upon hitting Post, the page componentcan refresh. Given appropriate access, a user can update an existingcomment. To do this, a user can click the Edit button next to a comment.Depending on the UI, this can either pop up an editor (from CommentsInfo pane) pre-populated with the comment, or display an in-line textbox (from Comments page component) pre-populated with the comment. Userscan save their changes, or Cancel out of them.

Given appropriate access, a user can delete an existing comment. Aconfirmation dialog pops open when the Delete button is clicked.

Users can reply to top-level comments. Replies to replies need not besupported. Adding, editing and deleting replies are identical to doingthat for top-level comments.

Comments can be ordered, at each level (either the top level or thereply level for each top-level comment) by date descending, i.e., thelatest comments are listed first. There is no UI for sorting.

In one embodiment, only one comments page component is used per page.

As a user edits a page, Constructor, can keep track of all theirchanges. In addition, when a user saves a page, Constructor canautomatically create a new version of that page. As a page's versionhistory builds up, users can revert to old versions of pages, can deleteold versions of pages, and can even navigate to and view old versions ofpages.

The same applies to documents, except that instead of navigating to oldversions of documents, users can download old versions of documents.Page editing can be equivalent to document uploads. When editing a page,users can have the option of either saving the given changes as a draft,or publishing their changes. When users save their changes as a draft,they effectively are not versioning the page, but instead are keepingtheir changes around for later review. Once a user is ready to submittheir changes to the system, they can click Publish, at which point anew version of a page is created, and that version can be set as the“active” version. Any time a user navigates to a given page, they caneffectively navigate to the “active” version. In one embodiment, thecase of documents, there are two ways to add a new version: (a) userscan upload to a page a document, and if that document has the same nameas a document already attached to the given page, then that document isadded as a new version of the existing attached document, or (b) userscan upload to a specific document a new version, and even if the namesare different, the new file is treated as a new version of that existingdocument.

Users can revert to any version of a page that exists in the system.After reverting to an old version of a page, say from version 10 toversion 6, versions later than the now “active” version need not bedeleted (versions 7-10 are not deleted). Reverting can be performed toan older version, or a newer version, given the relative position of the“active” version. Users can revert to a later version from a previousversion. When users revert to an old version, and then publish thatversion (after perhaps making some changes), the new version is tackedon to the very end of the version history, and is marked “latest”. Thesame exact behavior applies to documents (except uploading replacespublishing).

Users can delete any given version of a page, or all versions of a page(which effectively happens when you delete a page). When a given versionis deleted, holes are left in the version history. This is to make clearto users that a given version, which may have had a specific purpose ormeaning, is now gone. There need be no other way to see that a givenversion has been deleted.

Users can navigate and view the contents of a given version (via theExplorer panel). When viewing that version, they can click a button torevert to that version, or delete that version. There is no UI forimmediately making changes to that version—i.e., that non-active versionis read-only. In the case of documents, users can download anynon-active version.

Modifying page settings versions a page.

Page component settings can be versioned with a page. So if you revertto a different version, settings on components may be different.

Annotations and documents need not be versioned with the page;annotations are not versioned, and documents are versionedindependently.

These are versioned as pages, independent of their underlying objects.All the same page versioning functionality can apply.

Customers can deploy Constructor in various ways: (a) stand-alone, (b)behind a product like Runner and (c) behind a product like ALI (formerlyknown as the Plumtree portal). To be able to deploy Constructor behindALI, several features are offered, tackling things like navigation-levelintegration, portlet-level integration and gateway-level integration.

With the Constructor installer comes a navigation tag that can bedeployed into portal navigation components. In most cases, this tag willbe deployed inside the out-of-the-box portal header, or a modifiedversion of the out-of-the-box portal header. The portal has two types ofnavigation: pluggable navigation and tag-based navigation (AdaptiveTags). Via portal Experience Definitions, customers can create rules todetermine which type of navigation to display on a given portal page. Inthe case of tag-based navigation, portlets can be used to render out theportal navigation scheme. In this case, the portal header can be aportlet (aka, a Web application that produces HTML), and is built out ofHTML and XML tags. In the out-of-the-box portal header, there are somedefault tags: one to list out My Pages, one to list out Communities, andso on. These tags are primarily ‘pt:ptdata’ tags, which are then wrappedby ‘pt:plugnav’ tags for actually rendering out the data as HTML/CSS/JS.Constructor can ship an additional LiveSpaces data tag that can beinserted into this portal header portlet to list out LiveSpaces next toMy Pages and Communities. This tag, when rendered out on the page via aUI tag, list out all the LiveSpaces to which a user has access. When auser clicks on one of these LiveSpace links, they can then be navigatedto a gatewayed Constructor page (the home page for the given LiveSpacerun through the portal gateway).

When viewing a Constructor page via the portal, it can be a requirementthat the Constructor page be gatewayed. Gatewaying is a simple concept:when attempting to view a Constructor page via the portal, the user(really, the user's browser) makes an HTTP request to the portal with aURL that the user wants to see, the portal then parses this URL andfigures out that the user wants to see a specific portlet, the portalthen makes an HTTP request for that Constructor page (which wasspecified via the URL), get back the HTML/CSS/JS etc. from Constructor,“transforms” that markup (makes all of the URLs gatewayed URLs), andthen finally returns that HTML to the user's browser. Gatewaying a pagealso allows the portal to scan the page and replace any Adaptive Tagswith their corresponding HTML/CSS/JS (this is used to support theLiveSpaces menu and injecting the portal header into the Constructorshell). User identity propagation can also do via the gateway. When theportal makes a request to Constructor it can send along userinformation, which Constructor can then uses to figure out whether ornot a user should have access to a given resource.

By default, when viewing Constructor through the portal, and when theappropriate Experience Definition is set up, the portal header canautomatically appear at the top of the Constructor page. This can besupported by a custom Constructor Adaptive Tag, which is embedded intothe default Constructor shell. When the portal transforms theConstructor page, it can see this Adaptive Tag and insert the portalheader HTML. As described above, this HTML can include a menu whichlists out Live Spaces. Customers have the flexibility to modify theirshell, and place this header insertion tag wherever they want.

Constructor can include a portlet template that can be deployed to theportal to allow users to create new portlets based off existingConstructor page components. When creating a new portlet, users choosethe Constructor Page Component Wizard, wherein they can choose anexisting Constructor page component to which they have access. Once theychoose this page component and hit Finish, this choice is stored as anAdministrative Preference for the new portlet instance, and wheneverthat portlet instance is displayed on a portal page, it can dynamicallysurface the given Constructor page component. There are a couplesecurity implications here: (a) a user cannot select a page component towhich they don't have access and (b) a user cannot view the contents ofa Constructor portlet which contains a page component to which theydon't have access. In the latter case, a friendly error message can bedisplayed. Unfortunately, we can't just hide the owning portlet. At anytime, given appropriate portal access, users can go back and point at adifferent Constructor page component. There are no restrictions in placeto prevent a user from deleting a Constructor page component beingsurfaced in the portal. Here, we'll again display a friendly errormessage telling the user that the content no longer exists. In general,page components should “work” and look just like the page components doinside of Constructor.

FIG. 5 shows an exemplary Gatewayed Constructor Page with Header TagDiagram.

FIG. 6 shows a LiveSpaces tag diagram.

DataSpaces can allow Constructor users to create a full-blown UI formanaging data. There can be a few DataSpace templates that ship withConstructor, e.g., RSS, blogging, and so on. In addition, users cancreate a DataSpace from scratch. Once a DataSpace is created, users canaccess the data in the DataSpace via a set of different URLs, eachunique to the DataSpace and the type of view on the data that URLprovides.

Use Cases: users can create DataSpaces for tracking things like featurelists, to-dos, customer phone calls, project tasks, and so on. Inaddition, DataSpaces will prove valuable for blogging, and for keepingtrack of information published by other Web sites (via RSS). DataSpacescan be important in that they let users add structured and unstructuredcontent to each of the views they express. So, for example, you couldimagine that for each feature listed in a feature list, one could attachrich text, documents, images, and even further, additional DataSpacesaround a single feature.

To create a new DataSpace, users can navigate to the Dashboard, andclick the Create a DataSpace link. This can pop up a wizard. The firststep users must take is to specify a template for their Data Space. Outof the box, there are several templates: blog, custom, and RSS. Inaddition, customers can add new DataSpace templates to this list, whichkey off data provided by external Web services. In total, there arethree “types” or “sources” of data: Local (blogging, custom, etc.), RSS(only RSS) and External (all the Web service based DataSpace templates).This partitioning is mainly an artifact of the server-sideimplementation of these DataSpaces, but also serves to help users decidethe type of DataSpace they want to create. In one embodiment, only LocalDataSpaces are read/write; all others are read-only. Once a user picks aDataSpace template, they are then navigated to a separate wizard,specific to that type of DataSpace. The next few features outline those.Common to all DataSpaces, however, is the fact that each has a Title, aURL, and a Description. This can make it easy to find (and navigate to)the DataSpace in the system once it has been created. Once one of thoseDataSpaces is created, the user can then navigated to either (a) thecomponent where the DataSpace will be surfaced or (b) to the List viewfor the DataSpace. This navigation decision is based on where theDataSpace was created from.

Once a user decides they want to create a custom DataSpace, either todisplay this DataSpace in its native UI, or via a page component, theycan be taken to the Custom DataSpace Configuration Wizard. In thiswizard, users can specify a set of fields for the DataSpace. Each ofthese fields has a set of properties: Field Title, Field Type, DisplayOrder, Is the Title Field?, Is Required?, and in the case of a DropDownfield, the options that show up in the DropDown menu. Users can specifyany title for each of these fields; users can specify the field type:Text, MultiLineText (shows up as an HTML textarea), RichText (shows upas a rich text field) and DropDown (shows up as an HTML select menu withoptions) and DynamicDropDown (shows up as an HTML select menu withoptions). Users can go back at any time and modify each of thesesettings.

Blog DataSpaces, like custom DataSpaces, can store their data inside theConstructor repository. The main difference between custom DataSpacesand blog DataSpaces is that Blog DataSpace has a pre-defined set offields, whereas custom DataSpaces let users define any number of fields.In addition, Blog DataSpaces have a pre-defined set of page templates todisplay their records. To create a Blog DataSpace, a user simply has tospecify a Title, URL, and Description, and then hit Finish. This thennavigates the user to the appropriate UI (either displaying this newBlog DataSpace inside a data-bound component, or navigating them to theEntry view so they can start entering new blog posts). Notabledifferences for Blog DataSpaces: (a) the List UI: the List UI for Blogsis formatted to look like a standard blog, also the List UI includes anArchive to display all blog posts that don't fit into the default List.The limit is 10 posts on the front page. Also, the Display UI for blogposts (records in the Blog DataSpace) is slightly different in that theUI for display the record is better fitted to a blog post (that has adefined set of fields like Title and Body); this UI also includes bydefault a Comments page component, so that users can comment on thegiven blog post. This functionality can take advantage of the Objects asPages feature in Constructor, where any record can be viewed as a page,and treated like a regular page.

When defining a custom DataSpace, users can specify the set of fieldsthat make up that DataSpace. This functionality is only available whencreating a custom DataSpace. When creating other types of DataSpaces,such as blogs, RSS, etc. these fields can be pre-defined for the user.In one embodiment, there are a few types of fields that are offered outof the box: (a) Text: text fields are surfaced through the UI as HTMLtext inputs, (b) Multi-line Text: multi-line text fields are surfacedthrough the UI as HTML textarea inputs, (c) Rich Text: rich text fieldsare surfaced through the UI as WYSIWYG inputs, (d) Dropdown: dropdownfields are surfaced through the UI as select pull-down menus with astatic list of options, (e) Dynamic Dropdown: dynamic dropdown fieldsare the same as normal dropdown fields, except that they are dynamicallypopulated with the contents of another DataSpace. When adding a field toa DataSpace, users can specify a Title for that field; this then is usedto display the title of a given field in DataTable columns, or as labelsin a Record Entry component. Also, users can specify which field in aDataSpace should be used as the Title field; this is then used wheneverthe “title” for the record needs to be displayed (in search results, indynamic dropdowns, etc.). Users can then specify whether a field isrequired, which is then enforced via the Record Entry component. Displayorder can govern the ordering of the fields when displayed via theConstructor UI. This ordering can manifest itself as eithertop-to-bottom (e.g., in a Record Entry view) or left-to-right (in aDataTable or Record List). Display order is only relevant for certaintypes of displays; e.g., the Blog Display view doesn't pay attention tothe display order property, i.e., the blog post title field will alwaysbe displayed at the top, in bold. You can change field types at anytime, with the exception that you can't switch to Dropdown or DynamicDropdown. Users, at any time, can delete fields from a custom DataSpace.

Users can create DataSpaces which pull their content in from an externalRSS feed. When creating an RSS DataSpace, users simply need to specify aURL for the given feed, and if the feed is secured, a username andpassword. Once this information is supplied, users can navigate to aList view or a Display view. The List view, like with the blog DataSpacetype, is custom to RSS. Also, RSS is read-only, so there is no “Entry”view. There is nothing particularly worth noting about the RSS viewoverrides other that they are slightly different to allow easierbrowsing/reading of the RSS data. At any time you view a feed or anitem, the RSS feed is requested. This means, it's expected that the feedor a given post should display real-time data. Users can update the RSSURL at any time. If a user changes the URL for an RSS feed, and if anObject as Page exists for a given post item, those Objects as Pages willbe left around for posterity.

Dynamic dropdown can be done.

DataSpaces in page components in one example. For example, if I create aFeature List DataSpace, I can then add a DataTable to a LiveSpace page,and then display that Feature List inside of that DataTable. Constructorcan allow users, when specifying a DataSpace for a page component, tocreate a new DataSpace at that time, or use an existing DataSpace. Whenchoosing an existing DataSpace, it can be pretty straightforward: theuser finds the DataSpace, hits Finish, and then it shows up in thecomponent. On the other hand, if a user is creating a new DataSpace todisplay it in a component, the workflow can follow as such: (1) open thepage component wizard, (2) specify that you want to create a newDataSpace to populate the given page component, (3) click Finish (4) theDataSpace Configuration Wizard pops open, (5) user does all theDataSpace configuration work described above, (5) user clicks Finish,(6) the LiveSpace page refreshes to display the newly created DataSpaceinside the component. At any time, users can go back and change theDataSpace that shows up in a component. Users can navigate to DataSpacescreated via components in the same way they can navigate to DataSpacescreated via the Dashboard.

To update a DataSpace, users can navigate to the DataSpace and click theDataSpace Settings button, or can open the DataSpace wizard from theOrganizer. Either way, the DataSpace Configuration Wizard pops open forthat particular DataSpace type. At this point, users can change any ofthe settings for the DataSpace, within limits. The constraints aredescribed above.

To delete a DataSpace, users can pop open the Configuration Wizard andclick Delete DataSpace. This deletes all records in the DataSpace, andall of the Object as Pages created from any of those records. Once theDataSpace is deleted, there need be no way to recover it.

Because Constructor will be sold to large organizations, it provides acore set of functionality around securing the data and functionality itprovides. The ability to govern who can do what in the system makes itpossible for users to enter sensitive business information intoConstructor without the risk of that information leaking to users whoreally shouldn't have access. Following the core characteristics of theConstructor system, security decisions are designed to be made,understood and interpreted by end users. Security can be applied at afairly global level, at which point it can cascade down to childobjects. This makes it easy to secure objects once, and continueworking. Alternately, a more granular approach can be used.

For a given securable container, such as (a) system, (b) LiveSpace or(c) DataSpace, a given user can have one of many roles. The set of rolesin Constructor can include: Guest, Reviewer, Creator, Publisher, Editor,and Administrator. A user having a given role can mean that user has acertain collection of privileges, which let them perform a certain setof actions within that given container. Moreover, having a certain rolefor a given container can also mean that a user can see certain datawithin the given container. For each of the containers described above,Constructor can ship a fixed set of roles a user can have. The roles foreach container differ slightly, and are described below. It's worthnoting that groups can also have roles, and that by being a member of agroup that has a role, a user assumes that role.

Roles can be collections of privileges. In one embodiment, there are astatic set of privileges: EDIT-LIVE SPACE, ANNOTATE-PAGES, CREATE_PAGES,DELETE ALL_PAGES, EDIT-ALL-PAGES, READ_PAGES, EDIT-ALL-AN NOTATIONS,DELETE-ALL-AN NOTATIONS, EDIT-RECORD SET, CREATE_RECORDS,DELETE-ALL-RECORDS, EDIT-ALL-RECORDS, READ-RECORDS, EDIT-ALL-RECORD-ANNOTATIONS, DELETE-ALL-RECORD-AN NOTATIONS, ANNOTATE-RECORDS. This listof privileges is hidden from end users. The roll-up of these privileges,however, can be exposed to users via roles. Therefore, when a user has agiven role, they then can have a collection of these privileges. Theseprivileges help govern what a user can see and do in the system.

Constructor can rely on a short list of groups to govern security at asystem level. These groups include: Constructor Administrators,LiveSpace Administrators, and DataSpace Administrators. The implicationsof being a member of one of these groups are described below.

Constructor can let users define ACLs (access control lists) forLiveSpaces and DataSpaces. ACLs help the system decide what a user cansee or do for a given container (LS or DS). ACLs take on a very simpleform, they are a list of principal/role pairs, where a principal iseither a user or a group, and a role is one of the roles describedabove. Users can choose users and groups with the user and group picker,which can be populated with users and groups from the ALI database. TheACL UI can allow full CRUD operations on the control list.

Security evaluation can be done when a user tries to access a givenresource or perform a given action. When this happens, a few things canoccur: (a) the user is in a role that has the ability to see the givenresource, or perform the given action on the given resource (b) the useris in a role that can see the resource, but can't perform the givenaction on the resource or (c) they can't even see the resource to beginwith (this won't happen very often - if it does, it's because a user hasgotten a hold of a URL to an object to which they don't have access).Because security is applied at the container level, security evaluationcan be done against the ACL of either the object in question (if theobject in question happens to be a container itself, like a LiveSpace),or a parent container of the object in question (e.g., if I'm trying toaccess a page, a document, a record, etc.). If a user doesn't have theability to do something, an exception propagates to the UI. This takesthe form of an error page, which lists out why they can't do whatthey're trying to do.

Constructor need not store information about users and groups, and caninstead rely on a portal product to do so. Any time a user tries to dosomething in Constructor, their user identity can be retrieved fromeither the portal or other session, and the mapped against thecorresponding ACL (which would include a role that is mapped to a portaluser or group they're in). Group membership evaluation can be done atruntime (but may be cached).

Whenever a container object is created, a default set of principals canbe added to the ACL for that object. This default set can include: (a)the portal Administrators group, (b) the principal who is creating theobject. This default list can be extended/modified by customers via anunsupported feature known as security templates.

Whenever a user performs an auditable action (modify, create, etc.),that can be stored with the given object. Through the UI, this actioncan then be displayed; e.g., Michael created this page. This can alwaysdisplay the appropriate name associated with the given user object inthe portal. If the name changes on the portal object, the name inConstructor should update wherever that user performed an action.

The Action Pane can provide a base set of functionality that allowsusers to interact with content surrounding a given page (or recordpage). This can include: other pages (or record pages), documents,records, DataSpaces, and so on. Usually, a user will use the Action Panewhen they want to navigate to another object in the system.

“This Space” is a section of the Action pane that can list out all ofthe objects included in the DataSpace or LiveSpace a user is viewing.When viewing a page or document page in a LiveSpace, this list caninclude: pages and documents. When viewing a record list, record entry,record display, or document page in a DataSpace this list can include:records and documents. In one embodiment, by default, when a page firstloads, the This Space section can display at most ten items (which is atmost five items of each type). The list can group the items by type, andin each section sorts the items by title (alphabetically). Users canexpand each group of items to display all of the items of the given type(all of the item of that type in the given space). Users can also chooseto search for items in the given space. Here, there can be a search box;when users type in this box, the list of items updates dynamically (asthey type). This query is identical to running a simple text query inthe Organizer. Here, search results are returned grouped by type andordered by relevance (based on the query string). Each search result isa hyperlinked title (or name if title doesn't exist) to the givenobject. No more information is provided in this list.

“All Space” can be the same section as This Space, except the filter isscoped to include all spaces in the system (all LiveSpaces andDataSpaces). This can work just like the This Space section except thatall types of objects are returned from across the entire system.

“Attachments” can be a list of all the documents attached to the givenpage (page, record list page, record entry page, record view page).Document pages need not have attachments. In one embodiment, like theThis Space section, by default, at most ten items are displayed. Userscan choose to expand this list to display all of the documents attachedto the given page. These documents can be sorted alphabetically (justlike the items in the This Space/All Spaces list). This can also be justa list of hyperlinked names/titles. Clicking on these links navigateusers to the document page for the given document. The only addition isthat under each link is a download link, which is a direct pointer tothe attachment file.

Every page in Constructor can have version history—every time a page isshared, a new version can be stored in the system. The Action pane candisplay the list of every version of the page, sorted by date created,descending. Using this list, users can navigate to and view an oldversion, and when viewing that version can perform a variety ofactions—Revert to the version or Delete the version. The version historylist can also include the comments entered in by users when they sharedthe given page. By default, when the page loads, only the last fiveversions are displayed. Users can toggle this list to display the entireversion history for a given page.

Comments can be part of every page, and by default, appear at the bottomof the page. This UI lists out the last five top-level comments on thegiven page, and their replies. There can be a link which expands thelist of comments to display all comments. To add a new comment to agiven page, a user can click the Add a Comment link at the top of thecomments list. This can display a simple text area into which a user cantype text. Potentially malicious content can be striped out. Once acomment is added, it can be added to the top of the list. The remainingset of functionality is described in detail in the Comments featurespecification.

When entering Write or Design mode, the Action and Comments panes can behidden.

The Dashboard can be Constructor's home page. In other words, when auser navigates to Constructors base URL (i.e., /Constructor/), this isthe page they say. The Dashboard can provide to users a launching pointto other parts of the system. It can include a list of recent activityin the system, a list of all of the outstanding drafts a current user isworking on, and a list of every LiveSpace and DataSpace in the system.With this set of information, a user can pretty quickly grasp whatcontent is being generated in the system. Moreover, the Dashboard is thelaunching point for creating new top-level objects, or spaces.

“Recent Activity” can be a list of the most recently active items inConstructor. Active items are those recently modified by a user. Thislist is made up of pages, records, documents, LiveSpaces and DataSpaces.Each item includes the following: title/name, hyperlink to navigate tothe object, date modified, and who modified the object. This list iscapped at ten items, sorted by date, descending.

“My Drafts” can be a list of all the page drafts currently open by theuser viewing the Dashboard. This can include regular pages, documentpages, record list pages, record entry pages and record display pages.Each item can include the following: title/name, hyperlink to navigateto the page, and date last saved. This list can be sorted alphabeticallyin ascending order. There need be no limit to the number of draftsdisplayed in this list.

“Spaces” can be a compound list, displaying either (a) all theLiveSpaces in the system or (b) all the DataSpaces in the system. Thereis a switch in the list that lets users view one of these sets ofobjects. Each item includes the following: title/name, hyperlink to thespace. This list is sorted alphabetically.

“Creative LiveSpace” can be a link to the Create LiveSpace wizard.

“Create DataSpace” can be a link to the Create DataSpace wizard.

“Browser Constructor” can be a link to the Organizer.

Enterprise DataSpaces can allow users to surface through Constructordata residing in other systems. This can be supported by fetchinginformation from external systems via Web services, or SOAP, to be moreexplicit. Enterprise DataSpaces can be very similar to other DataSpaces.In one example, enterprise DataSpaces can be read-only. Typical usecases around Enterprise DataSpaces can involve surfacing informationfrom CRM systems (to perhaps display customer support issues or salesinformation), surfacing information from ERP systems (to perhaps displayinventory information), or connecting to any number of free Web servicessuch as Google's SOAP-based search API.

The first step in allowing users to surface Web service-based data inConstructor is to create a DataSpace template for grabbing that data.Once a DataSpace template is defined (usually done by an IT developer),it can then show up in the Constructor UI, particularly in the NewDataSpace wizard, as part of the list of DataSpace templates. Like localDataSpace templates, Enterprise DataSpace templates can be defined viaXML files on the Constructor file system(under../webtier/record-set-templates/soap). Each of these EnterpriseDataSpace XML files must contain the following properties: (a)recordSource: this must be “soap” for the system to register thetemplate as one pointing to a SOAP endpoint, (b) recordSetURI: this canbe a pointer at the WSDL URL for the given Web service (in the case ofGoogle, this would be http://api.google.com/GoogleSearch.wsdl) (c)operation Name: this is the name of the operation that should be invokedwhenever an instance of this DataSpace template is instantiated (in thecase of getting search results from Google, this operation is calleddoGoogleSearch), (d) inputMessageName: SOAP operations require inputmessages (in the case of Google, this is also called doGoogleSearch),(e) portTypeName: another required pointer at the operation you needinvoked (in the case of Google, this is called GoogleSearchPort), (f)binding name: another required parameter (in the case of Google, this iscalled GoogleSearchBinding), (f) serviceName: another required parameter(in the case of Google, this is called GoogleSearchService), (g)recordSetXPath: this is an XPath expression that points at thecollection of items returned by the Web service call that you want tomap to Constructor's notion of records (in the case of the XML returnedby a Google search request, this would be//doGoogleSearchResponse/return/resultElements/item), (h)inputMessageParts: this is the data structure that is sent as part ofthe request to the given endpoint (this chunk of XML ends up beingexposed to end users when they configure an instance of the givenDataSpace template), recordTypeDefinition: this chunk of XML describesthe shape of the “items” that are returned by the given operation. Inone embodiment, changes to a DataSpace template do not apply toDataSpaces created from that template.

For an Enterprise DataSpace to be valid, it can expose a primary keyfield, which is a unique identifier that represents a given record (likea customer ID field for a list of customers from a CRM system). Thisprimary key can be used in a variety of contexts, but primarily to helpconstruct meaningful URLs to record pages for a given EnterpriseDataSpace.

Like RSS DataSpaces, Enterprise DataSpaces can be read-only. TheConstructor UI can reinforce this restriction by not displaying any sortof editable UI around Enterprise DataSpace data or structure (columnscannot be added, etc.).

Once a given DataSpace is defined and its records have been fetched atleast once, the records can be brought into the system become part ofthe search collection. This means that users can search for EnterpriseDataSpace records just like they can search for local or RSS DataSpacerecords.

Constructor can hold on to Enterprise DataSpace records, which can allowusers to decorate the pages that represent those records, and also allowusers to search for the given records. Constructor can update this cachewhen a given record is requested by a given user.

Enterprise DataSpaces don't have any special UI, other than just beingread only (which is basically the same experience as viewing alocal/custom DataSpace when you don't have rights to change anything).

The Organizer can be Constructor's primary search, browse andadministration interface. From a single screen, users can get access toevery navigable object in the system, from pages, to DataSpaces, todocuments. The Organizer can provide a range of controls for grouping,filtering, and searching for items—with the intention of making itincredibly easy to find objects and perform a standard set of actions onthem.

Users can get to the Organizer at any time by clicking the Organizerlink at the top of every page.

The Organizer can provide a single search box, into which users can typeany text. Once a user enters text, they can click the Search button,which will invoke a request against Constructor, asking for all itemsthat match the given query. This query will look for all items whosetitle matches the search string, whose description matches the searchstring, or who “contain” the search string. Not all items can containdata. Items like LiveSpaces and DataSpaces are more containers thanholders of data, so they can be excluded from content-level searches, soas to not pollute search results with a whole raft of secondary andtertiary objects (you wouldn't always want to return the parentLiveSpace for a given page, just because the LiveSpace “contains” thecontent by being the parent of the page that contains that content.

The Organizer lets users search for objects of the following type: page,record, LiveSpace, DataSpace, document, component. Common to theseobjects is the fact that they each have a URL, and are therefore“navigable”.

The Organizer can let users filter search results by type. The potentialoptions are: Any Type, Document, LiveSpace, DataSpace, Page Record, andComponent. By selecting one of these objects, users can constrain thesearch results to being only of a particular type.

Users can filter objects based on the date they were last modified. Theoptions are: Any Time, Today, Yesterday, This Week, This Month, and ThisYear. By selecting one of these options, users can constrain the searchresults to objects modified within the specified time range.

Users can constrain their query to only return objects where theirsearch string only matches the title of a given object, the description,or the contents.

Users can choose to group their search results, to make it easier todigest the information that's returned. Currently, users can group bytype (the object types described above, or by the Space containing thegiven objects. When grouping by Space, this means either by LiveSpace orby DataSpace, and a certain set of search results may include some itemswhich live in a LiveSpace, and some that live in a DataSpace. Eachgrouping lists at the top the grouping container—whether it's the typeof object, or the container. Each grouping can by default show fiveitems, but presents users with the ability to display all items in agiven group. Users can also choose to not group items.

Users can choose to sort search results by a number of criteria: rank,title, creation date, Last Modified date. Rank is tied directly to therank Lucene gives search results based on the relevancy of theircontents to the full-text search string.

Users can navigate to search results by clicking the hyperlinked titlefor the given search result. The behavior here is to drive navigation ofthe parent window that spawned the Organizer. The usage pattern can besimilar to that of using Windows Explorer to view and open documents inWindows.

When selecting a single item, users can click the “info & settings”button to view the wizard associated with the given item. The followingobject types can have wizards: LiveSpaces, DataSpaces, components andpages. This button can be disabled when an object that isn't one ofthese is selected, or when a user doesn't have the right to modify thegiven object (based on security).

Clicking “edit”, when a specific page or record is selected, cannavigate the user to edit mode for a page, and entry mode for a record.This button can be disabled when an object that isn't a page or a recordis selected. This button can also disabled when a user doesn't have theright to edit the given item.

Clicking on “delete”, when a given object is selected, can permanentlyremove the object from the system. This action can be performed onmultiple objects at once. This action, like the other actions, can begoverned by security access on the selected objects. Home pages can begrayed out.

The “View Contents” link shows up for items that contain other items,this can include: LiveSpaces, DataSpaces, pages and records (really,record pages). Clicking this button can refresh the search results todisplay the selected item, and all the items that item contains.LiveSpaces can contain pages, documents and components; DataSpacescontain records, documents and components; pages contain documents andcomponents; records (record pages) contain documents and components.

Groups can be toggled open and closed. The filtering/action sidebar canalso be toggled open and closed.

Users can select one item at a time, or by using standard SHIFT andCONTROL (COMMAND on Macs) keyboard commands, can select multiple items.

The Data Table can be a page component that lets users interact withdata via a page. Users can bind Data Tables to any type of DataSpace,and depending on the DataSpace type, can get a read-only or editableview of the given data.

In one embodiment, the Data Table can exist in one of three modes:Simple, Master-Detail or Spreadsheet. The primary difference betweenSimple and Master-Detail mode is that in Simple mode, adding or editingrecords is done via the DataSpace UI, rather than through an in-placeDetail view. When a user selects to add a record, they can be taken tothe New Record view for the given DataSpace, and when they choose toedit a given record, they are taken to the Record Entry view for thegiven DataSpace. Deleting records is identical for the two modes.Master-Detail mode includes a Detail view, which appears directly belowthe table any time a user wants to add a new record, or edit an existingrecord. The Detail view can include a form for adding or editing data,and a set of buttons for posting the given changes. Spreadsheet mode isdifferent from the other two modes in that it allows adding and editingrecords in-place, just like in Microsoft Excel. Like Simple mode,Spreadsheet mode does not have a Detail view. If a given DataSpace isread-only, and a user specifies Spreadsheet mode, the table reverts toSimple mode.

To use the Data Table, users can first bind it to a DataSpace.

The Data Table wizard can give users the option of binding to anexisting DataSpace, or creating a new DataSpace. In either case, theData Table can bind to any DataSpace type. In one embodiment, when aDataSpace is read-only (such as RSS or Enterprise), the table does notsupply add/edit controls. In all cases, the Data Table automaticallyrenders a column for every field in the DataSpace. Similarly, every rowin the Data Table corresponds to a record in the given DataSpace.

In any of the three modes, users can sort the records in the Data Tableusing any of the columns/fields displayed. In Constructor 1.0, sortingcan be done alphabetically.

In any of the three modes, users can filter the records in a Data Tableusing a text query. As a user types, the Data Table updates to displayrecords that contain the given text query in any of their fields.

Users can specify a page size for a Data Table (how many records show upon each page). If the total number of records in the DataSpace to whicha Data Table is bound exceeds this paging size, then the given DataTable provides controls to move between each page of records. Users canjump to the first page, last page, and between each of the pagesin-between.

In Simple mode, users can add new records/rows to the Data Table byclicking the Add Record button. This can navigate users to the NewRecord UI for the given Data Space. Once the user hits Finish they canbe navigated back to the page on which the table exists. InMaster-Detail mode, users can add new records/rows to the Data Table byclicking the Add Record button. This can pop open a blank form in theDetail view directly beneath the Data Table. Users can enter informationand hit Create to add a new record. Depending on the filtering andpaging conditions of the given table, the record may not appearimmediately in the Data Table (it may be filtered out, or naturallyappear in a page not displayed). In Spreadsheet mode, users can add newrecords by simply typing in the always-present empty row at the bottomof the table. Moving out of this row (up arrow, down arrow and Returnall are valid triggers) triggers the save command.

Record editing is similar to record addition. Simple mode - users arenavigated to the associated Record Entry page when they click on therecord link (the first column is always hyperlinked) and are navigatedback once they are done. Master-Detail mode—users are presented with aRecord Entry view in-place when clicking on the record link. Spreadsheetmode—users can simply click into a cell to start editing a given record.Moving out of a cell updates the record (whereas moving out of a rowcreates a new record).

In any of the three modes, each row can have a checkbox that lets usersselect a row. Once a row is selected, they can click the Delete Recordbutton to delete the record from the given DataSpace. The Delete Recordbutton is only enabled if a user has delete privileges on all therecords selected). The Delete Record button need not be displayed if thetable is bound to a read only data server.

The Record List can provide sealable page component for viewing datafrom DataSpaces with a significant amount of fields/columns/records.

Users can bind Record List to existing DataSpaces, or create newDataSpaces to back them.

Sorting can be fixed at Last Modified descending. In one embodiment,this can be configured.

Users can specify a page size for a Record List (how many records showup on each page). If the total number of records in the DataSpace towhich a Record List is bound exceeds this paging size, then the givenRecord List provides controls to move between each page of records.Users can jump to the first page, last page, and between each of thepages in-between.

Users can filter the records in a Record List using a text query. As auser types, the Record List updates to display records that contain thegiven text query in any of their fields.

Users add new records to the Record List by clicking the Add Recordbutton. This navigates users to the New Record UI for the givenDataSpace. Once the user hits Finish they are navigated back to the pageon which the Record List exists.

Record editing can be similar to record addition. Upon clicking the EditRecord link for a given record, users are navigated to the associatedRecord Entry page and are navigated back once they are done.

Embodiments of the present invention can include computer-based methodsand systems which may be implemented using conventional general purposeor a specialized digital computer(s) or microprocessor(s), programmedaccording to the teachings of the present disclosure. Appropriatesoftware coding can readily be prepared by programmers based on theteachings of the present disclosure.

Embodiments of the present invention can include a computer readablemedium, such as computer readable storage medium. The computer readablestorage medium can have stored instructions which can be used to programa computer to perform any of the features present herein. The storagemedium can include, but is not limited to, any type of disk includingfloppy disks, optical discs, DVD, CD-ROMs, micro drive, andmagneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, flash memoryor any media or device suitable for storing instructions and/or data.The present invention can include software for controlling both thehardware of a computer, such as general purpose/specialized computer(s)or microprocessor(s), and for enabling them to interact with a humanuser or other mechanism utilizing the results of the present invention.Such software may include, but is not limited to, device drivers,operating systems, execution environments/containers, and userapplications.

Embodiments of the present invention can include providing code forimplementing processes of the present invention. The providing caninclude providing code to a user in any manner. For example, theproviding can include transmitting digital signals containing the codeto a user; providing the code on a physical media to a user; or anyother method of making the code available.

Embodiments of the present invention can include a computer-implementedmethod for transmitting the code which can be executed at a computer toperform any of the processes of embodiments of the present invention.The transmitting can include transfer through any portion of a network,such as the Internet; through wires, the atmosphere or space; or anyother type of transmission. The transmitting can include initiating atransmission of code; or causing the code to pass into any region orcountry from another region or country. A transmission to a user caninclude any transmission received by the user in any region or country,regardless of the location from which the transmission is sent.

Embodiments of the present invention can include a signal containingcode which can be executed at a computer to perform any of the processesof embodiments of the present invention. The signal can be transmittedthrough a network, such as the Internet; through wires, the atmosphereor space; or any other type of transmission. The entire signal need notbe in transit at the same time. The signal can extend in time over theperiod of its transfer. The signal is not to be considered as a snapshotof what is currently in transit.

The forgoing description of preferred embodiments of the presentinvention has been provided for the purposes of illustration anddescription. It is not intended to be exhaustive or to limit theinvention to the precise forms disclosed. Many modifications andvariations will be apparent to one of ordinary skill in the relevantarts. For example, steps preformed in the embodiments of the inventiondisclosed can be performed in alternate orders, certain steps can beomitted, and additional steps can be added. The embodiments were chosenand described in order to best explain the principles of the inventionand its practical application, thereby enabling others skilled in theart to understand the invention for various embodiments and with variousmodifications that are suited to the particular used contemplated. It isintended that the scope of the invention be defined by the claims andtheir equivalents.

1. A system comprising: a web-based application constructor forconstructing a web display, the web-based application constructorobtaining data from heterogeneous data sources to produce the webdisplay; the web display containing page components and displaying thedata from at least some of the heterogeneous data sources, wherein theapplication constructor converts at least one object from aheterogeneous data source into a page component.
 2. The system of claim1, wherein the page components contain interactive elements.
 3. Thesystem of claim 1, wherein all page editing is versioned.
 4. The systemof claim 1, wherein the page component displayed to a user is controlledby roles and security.
 5. The system of claim 1, wherein page layout isversioned.
 6. The system of claim 1, wherein the version is stored at aremote server.
 7. The system of claim 6, wherein AJAX at a browser sendsthe version information to a remote server.
 8. The system of claim 1,wherein the heterogeneous data sources have Web Services schemas.
 9. Thesystem of claim 1, wherein at least one of the heterogeneous datasources is a relational database management system.
 10. The system ofclaim 1, wherein at least one of the heterogeneous data sources is acustomer relationship management system.
 11. The system of claim 1,wherein at least one of the heterogeneous data sources is an enterpriseresource planning system.
 12. The system of claim 1, further comprisingpage templates to create the display.
 13. The system of claim 1, whereinthe page components can include rich text.
 14. The system of claim 1,wherein page components have their own URL.
 15. The system of claim 1,wherein at least one page component is a view of data in a list.
 16. Thesystem of claim 1, wherein at least one page component is a view of datain a record.
 17. The system of claim 1, wherein at least one pagecomponent is a view of an ad-hoc application.
 18. The system of claim 1,wherein the display is constructed from available applications, whereinavailable applications can be dragged and dropped into page components.19. The system of claim 11, wherein at least one of the heterogeneousdata sources is a searchable resource and when the display provides fora search field into the searchable resource, the result of a search areshown in a page component of the display.